Many software development tools are available today for use by software designers (or “developers”) in creating various types of software applications. Software “designers” and “developers” are used interchangeably herein, and generally refer to anyone involved with using a software development tool (or “authoring tool”) for authoring a software application. Authoring may include coding, designing, and/or otherwise creating or modifying the software application. A software application, as used herein, generally refers to any application that may be executed by a processor (or interpreter of some type) in order to perform operations defined by the instructions of the software application, including as an example presenting a user interface to a display. One example of such a software application is a web page, which may be defined in a markup language, such as HTML, XML, etc., JavaScript, and/or other underlying page source code that may be read and interpreted by a browser to generate a corresponding output presentation of the web page to a display.
In a software development environment, a developer may interact with a software development tool for writing code, compiling the code, testing or debugging the code, and packaging the resulting application for deployment in a run-time environment. The software development tool may be implemented as a software application that is stored to a computer-readable medium and executed by a computer processor to perform the tasks associated with aiding a developer in the development of a software application. As one example, an integrated development environment (IDE) is commonly used for developing software applications. In general, an IDE is a programming environment that has been packaged as a software application program, typically including a code editor, a compiler, a debugger, and a graphical user interface (GUI) builder. The IDE may be a stand-alone application or may be included as part of one or more existing and compatible applications. IDEs provide a user-friendly framework for many modern programming languages, such as Visual Basic, Java, and PowerBuilder. IDEs for developing markup language (e.g., HTML, XML, etc.) applications are among the most commonly used.
Thus, IDEs provide software authoring tools that allow a developer (e.g., a web developer) to create web pages, websites, interactive applications, and the like for use by end users (e.g., visitors to websites). Various IDEs exist in the current marketplace, such as DREAMWEAVER®, available from Adobe Systems Incorporated, and FRONTPAGE®, available: from Microsoft Corporation. DREAMWEAVER is one example of a web authoring tool that allows web developers to design Hypertext Markup Language (HTML) web pages in both a code editor and a graphical-based design time environment. DREAMWEAVER also allows the developer to design in other markup languages, such as, for example, Extensible Markup Language (XML), Extensible HTML (XHTML), Active Server Page (ASP), COLDFUSION™ Markup Language (CFML™), and the like.
Many software application authoring tools, as may be provided by an IDE, are available today for use by software developers in creating various types of software applications, such as web pages and/or websites, including as examples such software code authoring tools as ADOBE® DREAMWEAVER® and MICROSOFT® FRONTPAGE®. Certain authoring tools, such as ADOBE® DREAM WEAVERS, allow a developer to create a document in an environment that includes both a text-based code view and a graphical-based design view. The code view renders the source code (e.g., markup language code, scripting language code, stylesheet code, etc.) as text in a portion of the screen and allows the developer to see and manipulate the source code in the document file. For example, the developer may write and edit HTML or Cascading Style Sheets (CSS) code in the code view.
The design view (or “display view”), on the other hand, is a What You See Is What You Get (WYSIWYG) view of the output presentation document (e.g., web page) that is to be generated by an interpreter (e.g., a browser) as a result of interpreting one or more of the source files (e.g., html file, CSS file, etc.), and thus the design view allows the user to visually manipulate the interpreted and graphically laid-out version of the output presentation document, such as, for example, by dragging, dropping, cutting, and pasting visual components. As discussed further herein, the design view may employ techniques similar to those employed by browsers for presenting a mimicked output presentation document, which may be similar but is quite often not identical to an actual output presentation document that will be rendered by a browser at run-time. The design view provides an editable view of the output presentation document, rather than a run-time view of such output presentation document, wherein the developer may manipulate such output presentation within the design view. As the developer works, changes to the document are reflected in both the code view and the design view.
Once a designer creates source code (which may be referred to as a “source page” or “source file”), such source code is typically stored to a web server that is accessible by clients via a communication network, such as the Internet. The clients may access the web server and download the source code, which a browser executing on the client's computer interprets to generate a corresponding run-time output presentation, as is well known in the art.
Many software applications, such as web pages, comprise a plurality of source files that may be used by an interpreter (e.g., a browser) to build a resulting run-time output presentation. For instance, many web pages comprise a main file with one or more related files. A “related file,” as used herein, refers generally to a file required to build another document, such as an output presentation document. In some software development tools, such as DREAMWEAVER, these related files may be referred to as “dependent” files. For instance, a main file may be created that references one or more related files that must also be accessed/interpreted in order to generate a presentation output document. As an example, a main web page document (e.g., main HTML document) may be created that references other related files that are used to generate at least a portion of the presentation output that is to be presented by a client's browser for the web page. For instance, a main web page document may reference such related files as images, external style sheets, scripting language files (e.g., JavaScript files, etc.), and/or other files that a browser loads when it loads the web page. The browser may use the various related files to construct the run-time output presentation document that is presented to the client.
As one example, style sheets, such as cascading style sheet (“CSS”), are commonly employed to help readers of web pages (e.g., browsers) to define visual layout of a web page's content, such as colors, fonts, layout, and other aspects of document presentation. In this manner, the style sheet may be designed primarily to enable the separation of document content (written in HTML or a similar markup language, e.g., in a main file) from document presentation (written in CSS). Thus, the main HTML file for a web page may be authored to define certain content and/or reference one or more other related files that provide certain content (e.g., image files) that is desired to be presented in a run-time output presentation document that is to be generated when the web page is interpreted by an interpreter program (such as a client browser), and the main HTML file may reference one or more style sheets that define the visual layout of such content that is desired to be generated within the run-time output presentation document. Such use of style sheets are well known in the art.
As another example, scripting language files, such as JavaScript (JS) files, are commonly employed to provide functions that may be executed during run-time of a web page by a browser to further define the visual presentation and/or actions of the run-time output presentation document presented by the browser. Thus, a main web page document (e.g., main HTML document) may reference one or more scripting language files that are invoked for imparting certain functionality for the run-time output presentation document presented by the browser. Such use of scripting language files are also well known in the art.
Web authors generally create and edit web pages that comprise a main file (e.g., a main HTML file) with many related files, such as external JS, CSS, XML, and/or other server-side files, such as other HTML files, ColdFusion Markup Language (CFML) files, PHP files, or active server pages (ASP) files. This is the common way to construct web pages to allow sharing and re-use of components, and the authored web pages can thus become fairly complex.
Thus, when authoring a web page (or website comprising a collection of web pages), a developer often desires to author/edit not only a main file, but also the various related files to arrive at source files that when interpreted by a browser result in a desired run-time output presentation document being generated.
Certain source files of a web page may be referred to herein as “static” code in that they provide code that is merely read by a browser to present a corresponding static output presentation. Many HTML source files are static in this way. On the other hand, certain source files may be referred to herein as “dynamic” code in that they provide functions that may be executed during run-time of a web page responsive to events, such as user actions. In some instances, such dynamic code may provide functionality similar to that commonly offered by software application programs. For instance, dynamic code may provide functionality to perform certain actions responsive to cursor hover events (e.g., present a drop-down menu or other information responsive to a user's cursor being hovered over a particular portion of the page, such as over a button or menu item presented on the page). As another example, dynamic code may perform database searches, perform calculations, and/or trigger other functions responsive to user input. Thus, rather than merely presenting a static output presentation, the dynamic code may perform functions responsive to certain events encountered on the page, wherein the functions performed may result in a change to all or a portion of the page's output presentation. Such dynamic code is commonly implemented in scripting language files, such as JavaScript (JS) files, are commonly employed to provide functions that may be executed during run-time of a web page by a browser to further define the visual presentation and/or actions of the run-time output presentation document presented by the browser.
As mentioned above, some software development environments, such as DREAM WEAVER, provide not only a code view interface, but also provide a design view interface. Traditional design view interfaces present a mimicked view of the output presentation document (e.g., web page) that is to be generated by an interpreter (e.g., a browser) as a result of interpreting one or more of the source files (e.g., html file, CSS file, etc.). Such a mimicked view may be similar, but is quite often not identical, to an actual output presentation document that will be rendered by a browser at run-time.
One reason why the design view may not present an identical output presentation document as that which is generated at run-time by a browser is because of changes that occur along various points of delivery of the page. That is, the source files may change at various points along delivery of the source files from a hosting server (e.g., web server) to the point of actual run-time output presentation by a browser. For instance, source files that are authored and uploaded to a hosting server may thereafter be modified (e.g., by other files) on the server side before delivery to a requesting client. For instance, one or more of the source files that are authored and uploaded to a hosting server may be modified at the server by PHP, ColdFusion Markup Language (CFML), or active server pages (ASP) files.
Additionally, after the source files are delivered to a requesting client, further modifications may occur to those files at the client, prior to generating the output presentation document. As an example, certain information may be populated into a page from a file, database, search engine, etc. For instance, a given output presentation page may display a list of hyperlinks to pages that are found on the Web by a search engine in response to a user's search query, wherein the actual list of items that are displayed are supplied during run-time of the page by another source (e.g., a search engine). As another example, information regarding products in a company's inventory, corresponding product prices, and other product information may be dynamically loaded to a run-time output presentation page from a database.
Further still, additional changes may occur dynamically during run-time presentation of the output presentation document at the client side based, for instance, on a user's actions, web page or browser states, etc. For instance, on-load handling for non-intrusive JavaScript may be performed to modify the source file(s). Also, external JavaScript, AJAX (Asynchronous JavaScript and XML), and/or other scripting language source files may dynamically modify the output presentation document as events occur. Additionally, a stylesheet, such as CSS, may modify the source file(s) being interpreted by the browser for generating the output presentation document, and responsive to certain events, such as “hover”, etc., may result in dynamic code (e.g., JavaScript) modifying one or more of the source files based, at least in part, on a current state of the page and/or browser.
Accordingly, there are generally three main stages of source code (or source files) in web development. There is the “original” source that resides on the web server and is what a developer edits when the developer wants to make changes to a web page. There is the “delivered” source that is sent from the server to the browser. This is generally what is seen when the “View Source” is clicked in a client browser. This delivered source will also include any processing done by the server from the original source, especially for pages like PHP, ASP, CFML, etc. Lastly, there is the actual browser source, which is the source that represents the run-time output presentation page presented by the browser to a user at any specific time during run-time. This browser source thus includes any browser-side processing through code, such as JavaScript. This browser source can change as a user interacts with the page for performing such actions as menu selections, rollovers, search queries, etc.
Thus, as used herein, an “original” source file refers generally to a source file (e.g., html file, etc.) as it exists when uploaded to a hosting server, before modifications are made to the source file at a client to which it is downloaded. Further, a “delivered” source file refers to the source file as it exists when downloaded to a requesting client. The “delivered” source file may be the same as the “original” source file in some instances, or it may differ from the “original” source file as a result of certain modifications made to the original source file at the server (e.g., through certain server-side processing, particularly for pages like PHP, ASP, CFML, etc.). On the other hand, a “browser source” file refers generally to the source file as it exists after being modified at a client. In other words, the “browser source” file refers to the source tile, as modified by JavaScript, etc. at the client, which is actually being read/interpreted by a client browser for generating a run-time output presentation page. Such browser source file may, in some implementations, change from time to time, such as in response to different user actions (e.g., different user queries that are submitted to the page, etc.).
Generally, a traditional design view provided in a software development environment provides a mimicked output presentation view that is derived based on either original source files that are uploaded to a hosting server (prior to any modifications made, such as by PHP, etc., at the server) or based on the delivered source files that are downloaded from a server to a requesting client (prior to any modifications that occur at the client). Thus, the traditional design view may fail to accurately present a true representation of what the run-time output presentation document will be when generated by a browser (e.g., as result of processing a browser source file that is modified at the client). In some instances, the design view may present certain “placeholders” in its output presentation for information that is to be supplied at a later time (e.g., after the source files are loaded to the client), such as a placeholder for information that will be populated from a database, search engine, or other data source in response to a user's entered query.
Additionally, the mimicked view provided by the traditional design view provides an editing preview, rather than a run-time operational view of the output presentation document. For example, if a user clicks on a button presented in the mimicked output presentation document in the design view, the user may be allowed to edit the button, rather than activating the operational functionality of the button as when it is clicked in run-time.
In view of the above, web developers often utilize an external browser application (e.g., separate from the interfaces provided by the web development tool) to analyze the run-time characteristics of an output presentation document that is generated as a result of browser source files. For instance, once the developer authors original source files and uploads them to the hosting server, the developer may use an external browser application, such as Internet Explorer, to access the source files served by the hosting server, and thus analyze/test the resulting run-time output presentation document that is generated by the browser, as a result of the modified browser source files.
Then, if the user desires to make edits to the original source files that are served by the hosting server, the user must return to the development environment and try to locate the code in the corresponding original source file that is to be changed to effect the desired edit to the generated run-time output presentation document. The appropriate changes to make in the original source files in order to effect the desired changes in the run-time output presentation document may be difficult to recognize/understand by the developer, particularly since in the web development environment the developer is generally not viewing or editing the source files as they exist at the time that the browser is generating the run-time output presentation document. Rather, as mentioned above, the developer is often viewing and editing the original source files in the state at which they have when uploaded to the hosting server (or the delivered source files in the state at which they were served to the requesting client), rather than the browser source files as modified by the client.
Certain client-side testing environment tools are known in the art, such as FireBug™. Some of these tools may allow for source code to be viewed at a client site, such as run-time source code being used by a browser for generating a given run-time output presentation document. Further, some of these client-side testing environment tools may enable a user to modify the source code for testing of the resulting browser presentation of a run-time output presentation document. However, any such edits are only effected for the local, client-side document, and do not result in any changes to the server-side source files that are being served by the hosting web server.
When analyzing a run-time output presentation of a web page, a desire may arise for analyzing the page in a given state. Thus, it would be helpful to have an ability for an application that is being used for analyzing the page (e.g., a client-side testing environment, a web page authoring tool, etc.) to allow a user to freeze operation of dynamic code, such as JavaScript code, thereby allowing the user to view, analyze, and/or modify the page's output presentation and/or underlying source files at the given state at which it was frozen.